Wireless devices operating in the “Bluetooth” wireless communication spectrum are proliferating. In particular, the term “Bluetooth” generally refers to and defines a relatively short range wireless communication protocol, with an operating range ranging from a few meters to a few tens of meters. The Bluetooth specification includes various profiles that define the behavior associated with each communication endpoint to implement a specific use case. Several such use cases are contemplated in the Bluetooth specification, which are generally defined according to a protocol stack that promotes and allows interoperability between endpoint devices from different manufacturers through enabling applications to discover and use services that other nearby Bluetooth devices may be offering.
In that context, the Bluetooth specification defines device role pairs that together form a single use case called a profile. One example profile defined in the Bluetooth specification is the Handsfree Profile (HFP) for voice telephony, in which one device implements an Audio Gateway (AG) role and the other device implements a Handsfree (HF) device role. Another example is the Advanced Audio Distribution Profile (A2DP) for high-quality audio streaming, in which one device implements an audio source device (SRC) role and another device implements an audio sink device (SNK) role. For a commercial Bluetooth device that implements one role in a profile to function properly, another device that implements the corresponding role must be present within the radio range of the first device. For example, in order for an HF device such as a Bluetooth headset to function according to the Handsfree Profile, a device implementing the AG role (e.g., a cell phone) must be present within radio range. Likewise, in order to stream high-quality mono or stereo audio according to the A2DP, a device implementing the SNK role (e.g., Bluetooth headphones or Bluetooth speakers) must be within radio range of a device implementing the SRC role (e.g., a stereo music player).
The Bluetooth specification defines a layered data transport architecture and various protocols and procedures to handle data communicated between two devices that implement a particular profile use case. For example, various logical links are available to support different application data transport requirements, with each logical link associated with a logical transport having certain characteristics (e.g., flow control, acknowledgement/repeat mechanisms, sequence numbering, scheduling behavior, etc.). However, up to the Bluetooth 4.2 specification, Bluetooth Low Energy does not have specific support for isochronous data or flushing data. Accordingly, the Bluetooth Special Interest Group (SIG) has proposed to add isochronous data support to Bluetooth Low Energy, sometimes alternatively referred to as Bluetooth LE, BLE, BTLE, or Bluetooth Smart. In one proposed use case, one device called a “master” may broadcast isochronous data (e.g., time-bounded audio) to one or multiple “slave” devices via an Isochronous Connectionless (ICL) channel. To acquire (or reacquire) an ICL channel, a receiving device first needs to synchronize to a periodic advertising stream that points to the ICL channel. When the ICL channel changes to an inactive state (e.g., because audio has been paused), the receiving device generally remains synchronized to the periodic advertising stream such that once the ICL channel again becomes active, the receiving device will be notified via information conveyed in the periodic advertising stream. However, the proposed approach to convey ICL channel state changes via the periodic advertising stream is sub-optimal for various reasons. For example, because the receiver is required to switch between listening to the periodic advertising stream and the ICL channel, additional resources (e.g., memory and power) are consumed and latency increases, which can substantially interfere with performance especially on resource-constrained devices (e.g., with respect to available memory, power, etc.).